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RTP/RTCP Extension for RTP Splicing Notification 
Abstract 


Content splicing is a process that replaces the content of a main 
multimedia stream with other multimedia content and that delivers the 
substitutive multimedia content to the receivers for a period of 
time. The splicer is designed to handle RTP splicing and needs to 
know when to start and end the splicing. 


This memo defines two RTP/RICP extensions to indicate the splicing- 
related information to the splicer: an RTP header extension that 
conveys the information "in band" and an RTP Control Protocol (RTCP) 
packet that conveys the information out of band. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8286. 
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This document is subject to BCP 78 and the IETF Trust’s Legal 
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(https://trustee.ietf.org/license-info) in effect on the date of 
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carefully, as they describe your rights and restrictions with respect 
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Les 


Es 


Introduction 


Splicing is a process that replaces some multimedia content with 
other multimedia content and delivers the substitutive multimedia 
content to the receivers for a period of time. In some predictable 
splicing cases, e.g., advertisement insertion, the splicing duration 
needs to be inside of the specific pre-designated time slot. Certain 
timing information about when to start and end the splicing must be 
first acquired by the splicer in order to start the splicing. This 
document refers to this information as the "Splicing Interval". 


[SCTE35] provides a method that encapsulates the Splicing Interval 
inside the MPEG2-TS (MPEG2 transport stream) layer in cable TV 
systems. When transported in RTP, a middlebox designed as the 
splicer to decode the RTP packets and search for the Splicing 
Interval inside the payloads is required. The need for such 
processing increases the workload of the middlebox and limits the 
number of RTP sessions the middlebox can support. 


This document defines an RTP header extension [RFC8285] used by the 
main RTP sender to provide the Splicing Interval by including it in 
the RTP packets. 


However, the Splicing Interval conveyed in the RTP header extension 
might not reach the splicer successfully. Any splicing-unaware 
middlebox on the path between the RTP sender and the splicer might 
strip this RTP header extension. 


To increase robustness against such a case, this document also 
defines a new RTP Control Protocol (RTCP) packet type to carry the 
same Splicing Interval to the splicer. Since RTCP is also unreliable 
and may not be as "immediate" as the in-band technique, it’s only 
considered to be a complement to the RTP header extension. 


1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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In addition, we define the following terms: 

Main RTP Sender: 
The sender of RTP packets carrying the main RTP stream. 

Splicer: 
An intermediary node that inserts substitutive content into a main 
RTP stream. The splicer sends substitutive content to the RTP 
receiver instead of the main content during splicing. It is also 
responsible for processing RTCP traffic between the RTP sender and 
the RTP receiver. 

Splicing-In Point: 
A virtual point in the RTP stream, suitable for substitutive 
content entry, typically in the boundary between two independently 
decodable frames. 

Splicing-Out Point: 
A virtual point in the RTP stream, suitable for substitutive 
content exit, typically in the boundary between two independently 
decodable frames. 

Splicing Interval: 
The NIP timestamps, representing the main RTP sender wallclock 
time, for the splicing-in point and splicing-out point per 
[RFC6828], allowing the splicer to know when to start and end the 
RTP splicing. 

Substitutive RTP Sender: 


The sender of RTP packets carrying the RTP stream that will 
replace the content in the main RTP stream. 


2. Overview 

2.1. Overview of RTP Splicing 
RTP splicing is intended to replace some multimedia content with 
certain substitutive multimedia content and then forward it to the 
receivers for a period of time. This process is authorized by the 


main RTP sender that offers a specific time window for inserting the 
substitutive multimedia content in the main content. A typical usage 
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scenario is where an IPTV service provider uses its own regional 
advertising content to replace national advertising content, the time 
window of which is explicitly indicated by the IPTV service provider. 


The splicer is a middlebox handling RTP splicing. It receives the 
main content and substitutive content simultaneously but only chooses 
to send one of them to the receiver at any point in time. When RTP 
splicing begins, the splicer sends the substitutive content to the 
receivers instead of the main content. When RTP splicing ends, the 
splicer switches back to sending the main content to the receivers. 
This implies that the receiver is explicitly configured to receive 
the traffic via the splicer and will return any RTCP feedback to it 
in the presence of the splicer. 


The middlebox working as the splicer can be implemented as either an 
RTP mixer or an RTP translator. If implemented as an RTP mixer, the 
splicer will use its own synchronization source (SSRC), sequence 
number space, and timing model when generating the output stream to 
receivers, using the contributing source (CSRC) list to indicate 
whether the original content or substitutive content is being 
delivered. The splicer, on behalf of the content provider, can omit 
the CSRC list from the RTP packets it generates. This simplifies the 
design of the receivers, since they don’t need to parse the CSRC 
list, but makes it harder to determine when the splicing is taking 
place (it requires inspection of the RIP payload data, rather than 


just the RTP headers). A splicer working as an RIP mixer splits the 
flow between the sender and receiver into two, and it requires 
separate control loops for RTCP and congestion control. [RFC6828] 


provides an example of an RIP mixer approach. 


A splicer implemented as an RTP translator [RFC3550] will forward the 
RTP packets from the original and substitutive senders with their 
SSRCs intact but will need to rewrite RTCP Sender Report (SR) packets 
to account for the splicing. In this case, the congestion control 
loops run between the original sender and receiver and between the 
substitutive sender and receiver. The splicer needs to ensure that 
the RTCP feedback messages from the receiver are passed to the right 
sender to let the congestion control work. 


2.2. Overview of Splicing Interval 
To handle splicing on the RTP layer at the reserved time slots set by 
the main RTP sender, the splicer must first know the Splicing 
Interval from the main RTP sender before it can start splicing. 
When a new splicing is forthcoming, the main RTP sender needs to send 


the Splicing Interval to the splicer. The Splicing Interval SHOULD 
be sent by the RTP header extension or RTCP extension message more 
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than once to mitigate possible packet loss. To enable the splicer to 
get the substitutive content before the splicing starts, the main RTP 
sender MUST send the Splicing Interval well in advance. For example, 
the main RTP sender can estimate when to send the Splicing Interval 
based on the round-trip time (RIT), following the mechanisms 
described in Section 6.4.1 of [RFC3550] when the splicer sends an 
RTCP Receiver Report (RR) to the main sender. 


The substitutive sender also needs to learn the Splicing Interval 
from the main RTP sender in advance and estimate when to transfer the 
substitutive content to the splicer. The Splicing Interval could be 
transmitted from the main RTP sender to the substitutive content 
using some out-of-band mechanisms -- for example, a proprietary 
mechanism to exchange the Splicing Interval -- or the substitutive 
sender is implemented together with the main RTP sender inside a 
single device. To ensure that the Splicing Interval is valid for 
both the main RTP sender and the substitutive RTP sender, the two 
senders MUST share a common reference clock so that the splicer can 


achieve accurate splicing. The requirements for the common reference 
clock (e.g., resolution, skew) depend on the codec used by the media 
content. 


In this document, the main RTP sender uses a pair of NIP timestamps 
to indicate when to start and end the splicing to the splicer: the 
timestamp of the first substitutive RTP packet at the splicing-in 
point and the timestamp of the first main RTP packet at the 
splicing-out point. 


When the substitutive RTP sender gets the Splicing Interval, it must 
prepare the substitutive stream. The main content provider and the 
substitutive content provider MUST ensure that the RTP timestamp of 
the first substitutive RTP packet that would be presented to the 
receivers corresponds to the same time instant as the former 

NTP timestamp in the Splicing Interval. To enable the splicer to 
know the first substitutive RTP packet it needs to send, the 
substitutive RTP sender MUST send the substitutive RTP packet ahead 
of the splicing-in point, allowing the splicer to find out the 
timestamp of this first RTP packet in the substitutive RTP stream, 
e.g., using a prior RTCP SR message. 


When it is time for the splicing to end, the main content provider 
and the substitutive content provider MUST ensure that the RTP 
timestamp of the first main RTP packet that would be presented on the 
receivers corresponds to the same time instant as the latter 

NTP timestamp in the Splicing Interval. 
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3. Conveying Splicing Interval in RTP/RTCP Extensions 


This memo defines two backward-compatible RTP extensions to convey 
the Splicing Interval to the splicer: an RTP header extension and an 
RTCP splicing notification message. 


3.1. RTP Header Extension 


The RTP header extension mechanism defined in [RFC8285] can be 
adapted to carry the Splicing Interval, which consists of a pair of 
NTP timestamps. 


This RTP header extension carries the 7 octets of the splicing-out 
NTP timestamp (lower 24-bit part of the "Seconds" of an NTP timestamp 
and the 32 bits of the "Fraction" of an NTP timestamp as defined in 
[RFC5905]), followed by the 8 octets of the splicing-in NTP timestamp 
(64-bit NTP timestamp as defined in [RFC5905]). The top 8 bits of 
the splicing-out NIP timestamp are inferred from the top 8 bits of 
the splicing-in NIP timestamp, assuming that (1) the splicing-out 
time is after the splicing-in time and (2) the Splicing Interval is 
less than 2^25 seconds. Therefore, if the value of the 7 octets of 
the splicing-out NIP timestamp is smaller than the value of the 

7 lower octets of the splicing-in NIP timestamp, it implies a wrap of 
the 56-bit splicing-out NTP timestamp, which means that the top 8-bit 
value of the 64-bit splicing-out NTP timestamp is equal to the top 
8-bit value of the splicing-in NIP timestamp plus 0x01. Otherwise, 
the top 8 bits of the splicing-out NTP timestamp are equal to the top 
8 bits of the splicing-in NTP timestamp. 


This RTP header extension can be encoded using either the one-byte or 


two-byte header defined in [RFC8285]. Figures 1 and 2 show the 
Splicing Interval header extension with each of the two header 
formats. 
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0 f 2 3 
Oe 2 3 4 946 7 8 OOo. 2°34 B6 T BGO 2. SAO ONT. 8 OO T 


+o4-4-4-4-4-t-t-t-t-4- 4-4-4 -F-t ttt t-4-4-4-4-t-t-t-t-+-4-4-4-4+E 
| «Ip | u=14 | OUT NTP timestamp - Seconds (bit 8-31) | x 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| OUT NTP timestamp - Fraction (bit 0-31) |e 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+ +++ 
| IN NTP timestamp - Seconds (bit 0-31) |s 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| IN NTP timestamp - Fraction (bit 0-31) |o 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 


Figure 1: Splicing Interval Using the One-Byte Header Format 


0 1 2 3 
O n23% Aa 9) 0: of 28529, (0! 142! 3 AN 5° 6: EB 96 OL 2 3-416" FB 9. sO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 


| ID | L=15 | OUT NTP timestamp - Seconds |x 
FPP rt ata tartar tartan ta tanta tata ttt tata t atta tatatatatatatatatatt 
|OUT Secds (cont) | OUT NTP timestamp - Fraction le 
potato tartar toto tatotaotatatotcta ta e Ee Aa Aea AE E S e a S E a a AE A S 
| OUT Fract (cont) | IN NTP timestamp - Seconds |s 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 
| IN Secds (cont) | IN NTP timestamp - Fraction lo 


+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| IN Fract(cont)| 0 (pad) | AN 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++ 


Figure 2: Splicing Interval Using the Two-Byte Header Format 


Since the inclusion of an RTP header extension will reduce the 
efficiency of RTP header compression, it is RECOMMENDED that the main 
sender insert the RTP header extensions into a number of RTP packets, 
instead of all of the RTP packets, prior to the splicing-in. 


After the splicer obtains the RIP header extension and derives the 
Splicing Interval, it generates its own stream and is not allowed to 
include the RTP header extension in outgoing packets; this reduces 
header overhead. 


3.2. RTCP Splicing Notification Message 


In addition to including the RTP header extension, the main RTP 
sender includes the Splicing Interval in an RTCP splicing 
notification message. Whether or not the timestamps are included in 
the RTP header extension, the main RTP sender MUST send the RTCP 
splicing notification message. This provides robustness in the case 
where a middlebox strips RTP header extensions. The main RTP sender 
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MUST make sure that the splicing information contained in the RTCP 
splicing notification message is consistent with the information 
included in the RTP header extensions. 


The RTCP splicing notification message is a new RTCP packet type. It 
has a fixed header followed by a pair of NTP timestamps: 


0 1 2 3 

O EA 3 A E 8 Or De 23) 516. TB: 9? ODD E i 6 89 O A 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|v=2|P|reserved | PT=213 | length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SSRC | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IN NTP timestamp (most significant word) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IN NTP timestamp (least significant word) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OUT NTP timestamp (most significant word) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OUT NTP timestamp (least significant word) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: RTCP Splicing Notification Message 
The RTCP splicing notification message includes the following fields: 
Length: 16 bits 


As defined in [RFC3550], the length of the RTCP packet in 32-bit 
words minus one, including the header and any padding. 


SSRC: 32 bits 
The SSRC of the main RTP sender. 

Timestamp: 64 bits 
Indicates the wallclock time when this splicing starts and ends. 
The full-resolution NTP timestamp is used, which is a 64-bit 
unsigned fixed-point number with the integer part in the first 
32 bits and the fractional part in the last 32 bits. This format 


is the same as the NTP timestamp field in the RTCP SR 
(Section 6.4.1 of [RFC3550]). 
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The RICP splicing notification message can be included in the RTCP 
compound packet together with the RTCP SR generated at the main RTP 
sender; hence, it follows the compound RTCP rules defined in 
Section 6.1 in [RFC3550]. 


If the use of non-compound RTCP [RFC5506] was previously negotiated 
between the sender and the splicer, the RTCP splicing notification 
messages may be sent as non-compound RTCP packets. In some cases 
where the mapping from the RIP timestamp to the NTP timestamp 
changes, e.g., clock drift happens before the splicing event, sending 
an RTCP SR or even updated Splicing Interval information in a timely 
manner might be required in order to update the timestamp mapping for 
accurate splicing. 


Since the RTCP splicing notification message is intentionally sent by 
the main RTP sender to the splicer, the splicer is not allowed to 
forward this message to the receivers, so as to avoid useless 
processing and additional RTCP bandwidth consumption in the 
downstream receivers. 


4. Reducing Splicing Latency 


When splicing starts or ends, the splicer outputs the multimedia 
content from another sender to the receivers. Given that the 
receivers must first acquire certain information ([RFC6285] refers to 
this information as "Reference Information") to start processing the 
multimedia data, either the main RTP sender or the substitutive 
sender SHOULD provide the Reference Information together with its 
multimedia content to reduce the delay caused by acquiring the 
Reference Information. The methods by which the Reference 
Information is distributed to the receivers are out of scope for 

this memo. 


Another latency element is delay caused by synchronization. The 
receivers must receive enough synchronization metadata prior to 
synchronizing the separate components of the multimedia streams when 
splicing starts or ends. Either the main RIP sender or the 
substitutive sender SHOULD send the synchronization metadata early 
enough so that the receivers can play out the multimedia ina 
synchronized fashion. The main RTP sender or the substitutive sender 
can estimate when to send the synchronization metadata based on, for 
example, the RIT, following the mechanisms described in Section 6.4.1 
of [RFC3550] when the splicer sends an RTCP RR to the main sender or 
the substitutive sender. The main RTP sender and the substitutive 
sender can also be coordinated by some proprietary out-of-band 
mechanisms to decide when, and to whom, the metadata is to be sent. 
If both send the information, the splicer SHOULD pick one based on 
the current situation, e.g., choosing either (1) the main RTP sender 
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when synchronizing the main media content or (2) the information from 
the substitutive sender when synchronizing the spliced content. To 
reduce possible synchronization delay, it is RECOMMENDED that the 
mechanisms defined in [RFC6051] be adopted. 


5. Failure Cases 


This section examines the implications of losing RTCP splicing 
notification messages, e.g., the RTP header extension is stripped on 
the path. 


Given that there may be a splicing-unaware middlebox on the path 
between the main RTP sender and the splicer, the main and 
substitutive RTP senders can use one heuristic to verify whether or 
not the Splicing Interval reaches the splicer. 


The splicer can be implemented to have its own SSRC and send RTCP 
reception reports to the senders of the main and substitutive RTP 
streams. This allows the senders to detect problems on the path to 
the splicer. Alternatively, it is possible to implement the splicer 
such that it has no SSRC and does not send RICP reports; this 
prevents the senders from being able to monitor the quality of the 
path to the splicer. 


If the splicer has an SSRC and sends its own RTCP reports, it can 
choose not to pass RTCP reports it receives from the receivers to the 
senders. This will prevent the senders from being able to monitor 
the quality of the paths from the splicer to the receivers. 


A splicer that has an SSRC can choose to pass RTCP reception reports 
from the receivers back to the senders, after modifications to 
account for the splicing. This will allow the senders to monitor the 
quality of the paths from the splicer to the receivers. A splicer 
that does not have its own SSRC has to forward and translate RTCP 
reports from the receiver; otherwise, the senders will not see any 
receivers in the RTP session. 


If the splicer is implemented as a mixer, it will have its own SSRC, 
send its own RTCP reports, and forward translated RTCP reports from 
the receivers. 


Upon the detection of a failure, the splicer can communicate with the 
main sender and the substitutive sender via some out-of-band 
signaling technique and fall back to the payload-specific mechanisms 
it supports, e.g., the MPEG2-TS splicing solution defined in 
[SCTE35], or just abandon the splicing. 
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6. 


6. 


Iz 


Session Description Protocol (SDP) Signaling 


This document defines the URI for declaring this header extension in 
an "extmap" attribute to be 
"urn:ietf:params:rtp-hdrext:splicing-interval". 


This document extends the standard semantics defined in "The Session 
Description Protocol (SDP) Grouping Framework" [RFC5888] with a new 
semantic, called "SPLICE", to represent the relationship between the 
main RTP stream and the substitutive RTP stream. Only two "m=" lines 
are allowed in the SPLICE group. The main RTP stream is the one with 
the extended "extmap" attribute, and the other one is the 
substitutive stream. A single "m=" line MUST NOT be included in 
different SPLICE groups at the same time. The main RTP sender 
provides the information about both main and substitutive sources. 


The extended SDP attribute specified in this document is applicable 
for offer/answer content [RFC3264] and does not affect any rules when 
negotiating offers and answers. When used with multiple "m=" lines, 
substitutive RTP MUST be applied only to the RTP packets whose SDP 
"m=" line is in the same group with the substitutive stream using 
SPLICE and has the extended splicing "extmap" attribute. This 
semantic is also applicable for BUNDLE cases. 


The following examples show how SDP signaling could be used for 
splicing in different cases. 


Declarative SDP 


v=0 

o=xia 1122334455 1122334466 IN IP4 splicing.example.com 
s=RTP Splicing Example 

t=0 0 

a=group:SPLICE 1 2 

m=video 30000 RTP/AVP 100 

i=Main RTP Stream 

c=IN IP4 233.252.0.1/127 

a=rtpmap:100 MP2T/90000 

a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 
a=mid:1 

m=video 30002 RTP/AVP 100 

i=Substitutive RTP Stream 

c=IN IP4 233.252.0.2/127 

a=sendonly 

a=rtpmap:100 MP2T/90000 

a=mid:2 


Figure 4: Example SDP for a Single-Channel Splicing Scenario 
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The splicer receiving the SDP message above receives one MPEG2-TS 
stream (payload 100) from the main RIP sender (with a multicast 
destination address of 233.252.0.1) on port 30000 and/or receives 
another MPEG2-TS stream from the substitutive RIP sender (with a 
multicast destination address of 233.252.0.2) on port 30002. But at 
a particular point in time, the splicer only selects one stream and 
outputs the content from the chosen stream to the downstream 
receivers. 


6.2. Offer/Answer without BUNDLE 
SDP Offer - from the main RTP sender: 


v=0 

o=xia 1122334455 1122334466 IN IP4 splicing.example.com 
S=RTP Splicing Example 

t=0 0 

a=group:SPLICE 1 2 

m=video 30000 RTP/AVP 31 100 

i=Main RTP Stream 

c=IN IP4 splicing.example.com 

a=rtpmap:31 H261/90000 

a=rtpmap:100 MP2T/90000 

a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 
a=sendonly 

a=mid:1 

m=video 40000 RTP/AVP 31 100 

i=Substitutive RTP Stream 

c=IN IP4 substitutive.example.com 

a=rtpmap:31 H261/90000 

a=rtpmap:100 MP2T/90000 

a=sendonly 

a=mid:2 
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SDP Answer - from the splicer: 


v=0 

o=xia 1122334455 1122334466 IN IP4 splicer.example.com 
S=RTP Splicing Example 

t=0 0 

a=group:SPLICE 1 2 

m=video 30000 RTP/AVP 100 

i=Main RTP Stream 

c=IN IP4 splicer.example.com 

a=rtpmap:100 MP2T/90000 

a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 
a=recvonly 

a=mid:1 

m=video 40000 RTP/AVP 100 

i=Substitutive RTP Stream 

c=IN IP4 splicer.example.com 

a=rtpmap:100 MP2T/90000 

a=recvonly 

a=mid:2 


Offer/Answer with BUNDLE: All Media Are Spliced 


In this example, the bundled audio and video media have their own 
substitutive media for splicing: 


1. 


Xia, 


An offer, in which the offerer assigns a unique address anda 
substitutive media to each bundled "m=" line for splicing within 
the BUNDLE group. 


An answer, in which the answerer selects its own BUNDLE address 
and leaves the substitutive media untouched. 
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SDP Offer - from the main RTP sender: 


v=0 

o=alice 1122334455 1122334466 IN IP4 splicing.example.com 
S=RTP Splicing Example 

c=IN IP4 splicing.example.com 

t=0 0 

a=group:SPLICE foo 1 
a=group:SPLICE bar 2 
a=group:BUNDLE foo bar 

m=audio 10000 RTP/AVP 0 8 97 
a=mid: foo 

b=AS:200 

a=rtpmap:0 PCMU/8000 

a=rtpmap:8 PCMA/8000 

a=rtpmap:97 iLBC/8000 

a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 
a=sendonly 

m=video 10002 RTP/AVP 31 32 
a=mid:bar 

b=AS:1000 

a=rtpmap:31 H261/90000 
a=rtpmap:32 MPV/90000 

a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 
a=sendonly 

m=audio 20000 RTP/AVP 0 8 97 
i=Substitutive audio RTP Stream 
c=IN IP4 substitutive.example.com 
a=rtpmap:0 PCMU/8000 

a=rtpmap:8 PCMA/8000 

a=rtpmap:97 iLBC/8000 

a=sendonly 

a=mid:1 

m=video 20002 RTP/AVP 31 32 
i=Substitutive video RTP Stream 
c=IN IP4 substitutive.example.com 
a=rtpmap:31 H261/90000 
a=rtpmap:32 MPV/90000 

a=mid:2 

a=sendonly 
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SDP Answer - from the splicer: 


v=0 

o=bob 2808844564 2808844564 IN IP4 splicer.example.com 
S=RTP Splicing Example 

c=IN IP4 splicer.example.com 
t=0 0 

a=group:SPLICE foo 1 
a=group:SPLICE bar 2 
a=group:BUNDLE foo bar 

m=audio 30000 RTP/AVP 0 

a=mid: foo 

b=AS:200 

a=rtpmap:0 PCMU/8000 

a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 
a=recvonly 

m=video 30000 RTP/AVP 32 
a=mid:bar 

b=AS:1000 

a=rtpmap:32 MPV/90000 
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 
a=recvonly 

m=audio 30002 RTP/AVP 0 
i=Substitutive audio RTP Stream 
c=IN IP4 splicer.example.com 
a=rtpmap:0 PCMU/8000 

a=recvonly 

a=mid:1 

m=video 30004 RTP/AVP 32 
i=Substitutive video RTP Stream 
c=IN IP4 splicer.example.com 
a=rtpmap:32 MPV/90000 

a=mid:2 

a=recvonly 


6.4. Offer/Answer with BUNDLE: A Subset of Media Are Spliced 


In this example, the substitutive media only applies for video when 


splicing: 


1. An offer, in which the offerer assigns a unique address to each 


bundled "m=" line within the BUNDLE group and assigns a 


substitutive media to the bundled video "m=" line for splicing. 


2. An answer, in which the answerer selects its own BUNDLE address 


and leaves the substitutive media untouched. 
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SDP Offer - from the main RTP sender: 


Xia, 


v=0 

o=alice 1122334455 1122334466 IN IP4 splicing.example.com 
S=RTP Splicing Example 

c=IN IP4 splicing.example.com 

t=0 0 

a=group:SPLICE bar 2 
a=group:BUNDLE foo bar 

m=audio 10000 RTP/AVP 0 8 97 
a=mid: foo 

b=AS:200 

a=rtpmap:0 PCMU/8000 

a=rtpmap:8 PCMA/8000 

a=rtpmap:97 iLBC/8000 

a=sendonly 

m=video 10002 RTP/AVP 31 32 
a=mid:bar 

b=AS:1000 

a=rtpmap:31 H261/90000 
a=rtpmap:32 MPV/90000 

a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 
a=sendonly 

m=video 20000 RTP/AVP 31 32 
i=Substitutive video RTP Stream 
c=IN IP4 substitutive.example.com 
a=rtpmap:31 H261/90000 
a=rtpmap:32 MPV/90000 

a=mid:2 

a=sendonly 


2017 
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Aes 


SDP Answer - from the splicer: 


v=0 

o=bob 2808844564 2808844564 IN IP4 splicer.example.com 
S=RTP Splicing Example 

c=IN IP4 splicer.example.com 
t=0 0 

a=group:SPLICE bar 2 
a=group:BUNDLE foo bar 

m=audio 30000 RTP/AVP 0 

a=mid: foo 

b=AS:200 

a=rtpmap:0 PCMU/8000 

a=recvonly 

m=video 30000 RTP/AVP 32 
a=mid:bar 

b=AS:1000 

a=rtpmap:32 MPV/90000 
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 
a=recvonly 

m=video 30004 RTP/AVP 32 
i=Substitutive video RTP Stream 
c=IN IP4 splicer.example.com 
a=rtpmap:32 MPV/90000 

a=mid:2 

a=recvonly 


Security Considerations 


The security considerations of the RTP specification [RFC3550] and 
the general mechanism for RTP header extensions [RFC8285] apply. The 
splicer can be either a mixer or a translator, and all the security 
considerations of topologies [RFC7667] [RFC7201] for these two types 
of RTP intermediaries are applicable for the splicer. 


The splicer replaces some content with other content in RTP packets, 
thus breaking any RTP-level end-to-end security, such as source 
authentication and integrity protection. End-to-end source 
authentication is not possible with any known existing splicing 
solution. A new solution can theoretically be developed that enables 
identification of the participating entities and what each provides, 
i.e., the different media sources -- main and substitutive -- and the 
splicer, which provides the RTP-level integration of the media 
payloads in a common timeline and synchronization context. 


Since the splicer breaks RTP-level end-to-end security, it needs to 
be part of the signaling context and the necessary security 
associations (e.g., Secure Real-time Transport Protocol (SRTP) 
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[RFC3711] crypto contexts) established for the RTP session 
participants. When using SRIP, the splicer would have to be 
provisioned with the same security association as the main RTP 
sender. 


If there are concerns about the confidentiality of the splicing time 
information, the header extension defined in this document MUST also 
be protected; for example, header extension encryption [RFC6904] can 
be used in this case. However, the malicious endpoint may get the 
splicing time information by other means, e.g., inferring it from the 
communication between the main and substitutive content sources. To 
avoid the insertion of invalid substitutive content, the splicer MUST 
have some mechanisms to authenticate the substitutive stream source. 


For cases where the splicing time information is changed by a 
malicious endpoint, the splicing, for example, may fail, since it 
will not be available at the right time for the substitutive media to 
arrive. Another case is one where an attacker may prevent the 
receivers from receiving the content from the main sender by 
inserting extra splicing time information. To avoid the above 
scenarios, the authentication of the RTP header extension for 
splicing time information SHOULD be considered. 


When a splicer implemented as a mixer sends the stream to the 
receivers, the CSRC list, which can be used to detect RTP-level 
forwarding loops as defined in Section 8.2 of [RFC3550], may be 
removed for simplifying the receivers that cannot handle multiple 
sources in the RTP stream. Hence, loops may occur, causing packets 
to loop back to a point upstream of the splicer and possibly forming 
a serious denial-of-service threat. In such a case, non-RTP means, 
e.g., Signaling among all the participants, MUST be used to detect 
and resolve loops. 


8. IANA Considerations 
8.1. RICP Control Packet Types 
Based on the guidelines suggested in [RFC8126], a new RTCP packet 
format has been registered in the "RTCP Control Packet types (PT)" 
registry: 
Name: SNM 
Long name: Splicing Notification Message 


Value: 213 


Reference: This document 
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82°. 


RTP Compact Header Extensions 


IANA has registered a new RIP Compact Header Extension [RFC8285], 
according to the following: 


Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval 
Description: Splicing Interval 

Contact: Jinwei Xia <xiajinwei@huawei.com> 

Reference: This document 


SDP Grouping Semantic Extension 


IANA has registered the new SDP grouping semantic extension called 
"SPLICE" in the "Semantics for the ’group’ SDP Attribute" subregistry 
of the "Session Description Protocol (SDP) Parameters" registry: 


Oke 


Semantics: Splice 
Token: SPLICE 


Reference: This document 
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